Scheduling delivery of products via the Internet

ABSTRACT

Methods and apparatus for scheduling delivery of an order via a wide area network. A computer system associates a customer point value with each customer according to a customer point system. The customer point values is determined with reference to customer order data. The computer system then divides the customers into customer groups, each of which has a range of customer point values. The system determines an actual capacity allocation distribution among the customer groups based on the customer order data. The system adjusts the range of customer point values for customer groups to cause the actual capacity allocation distribution to converge to a target capacity allocation distribution.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.09/810,891, filed Mar. 16, 2001, which is incorporated herein byreference for all purposes, and which claims priority to: (i) U.S.Provisional Patent Application No. 60/247,828 for “SCHEDULING DELIVERYOF PRODUCTS VIA THE INTERNET” filed on Nov. 9, 2000, which isincorporated herein by reference for all purposes; and (ii) U.S. patentapplication Ser. No. 09/568,613 for “SCHEDULING DELIVERY OF PRODUCTS VIATHE INTERNET” filed on May 10, 2000, which is incorporated herein byreference for all purposes.

BACKGROUND OF THE INVENTION

The present invention relates to the field of electronic commerce. Inparticular, the invention relates to a technique for selling anddelivering consumer products to customers using a data network. Stillmore specifically, the present invention provides methods and apparatusby which scheduling of deliveries for products ordered through thepresent system is provided via the Internet.

Electronic commerce via the Internet is rapidly changing the way inwhich products and services are purchased by and delivered to consumers.An important challenge faced by most businesses engaging in commerceover the Internet relates to the manner in which their products actuallyget to consumers.

Most Internet retailers rely on third party services such as UPS andFederal Express to deliver the products purchased on their sites. Thismodel has some advantages for the retailers in that they don't have toinvest in and develop delivery infrastructures. However, the downside isthe potential negative effects such a model has on customersatisfaction. That is, once an order is picked up from the retailer bythe delivery service, the retailer loses control of the remainder of thetransaction and runs the risk that any mistakes by the delivery servicewill reflect negatively on the retailer. For example, the retailer lacksthe ability to deliver products during precise delivery windows. Ratherthey must rely on the delivery service which may make the customer waitaround for inconveniently long periods of time.

In addition, if the customer's order is damaged or incorrect, there isno immediate recourse for the customer because the delivery service isnot controlled by the retailer. The customer must typically go through arather cumbersome process to return the order using the same or someother third party delivery service. This can intensify any feelings offrustration the customer might have with regard to the error. Obviouslythis is undesirable from the retailer's perspective.

In view of the foregoing, there is a need for techniques which allowe-commerce retailers to efficiently develop effective deliverycapabilities. More specifically, there is a need for techniques by whichsuch retailers may affect precise delivery of their products tocustomers.

SUMMARY OF THE INVENTION

According to the present invention, methods and apparatus are providedby which the delivery of products ordered over the Internet may bescheduled in an effective and precise manner. The techniques describedherein allow an e-commerce retailer to communicate precise availabledelivery windows to a customer over the Internet which reflect anaccurate picture of the product and delivery resources which areactually available at the time the customer schedules the delivery. Thatis, when a customer indicates that scheduling of a delivery is desired,the system of the present invention computes and displays the availabledelivery windows to the customer which, according to a specificembodiment, are half-hour windows. The techniques of the presentinvention are then able to schedule the delivery window selected by thecustomer without compromising any previous commitments made to othercustomers. This is accomplished by generating the delivery window gridand scheduling the selected window with reference to available resourcecapacity which is reflective of the previous commitments.

Thus, the present invention provides methods and apparatus forassociating a customer point value with each customer according to acustomer point system. One embodiment of a computer system according tothe present invention divides the customers into customer groups, eachof which corresponds to a range of customer point values. Each customeris assigned to one of the customer groups according to the associatedcustomer point value. The system determines an actual capacityallocation distribution among the customer groups with reference to thecustomer order data. Then, the system or the administrator of the systemadjusts the range of customer point values associated with customergroups to cause the actual capacity allocation distribution to convergeto a target capacity allocation distribution.

According to another embodiment, methods and apparatus are described fordetermining which of the plurality of delivery windows are available fordelivery of an order with reference to currently available systemresources and a customer profile.

A further understanding of the nature and advantages of the presentinvention may be realized by reference to the remaining portions of thespecification and the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an integrated system architecture inaccordance with a specific embodiment of the present invention.

FIG. 2 is a diagram illustrating a “hub and spoke” distribution systemaccording to a specific embodiment of the present invention.

FIG. 3 is a flow diagram which illustrates the interactions betweensoftware modules which effect the delivery scheduling process accordingto a specific embodiment of the present invention.

FIG. 4 is a flowchart illustrating the delivery scheduling processaccording to a specific embodiment of the invention.

FIG. 5 is a flowchart illustrating generation of the delivery windowgrid according to a specific embodiment of the present invention.

FIG. 6 is a flowchart illustrating allocation of the system capacitybased on customer order data.

FIG. 7 is a factor table illustrating relationships between an averageshipment size and a customer point value.

FIG. 8 is a factor table illustrating relationships between a shipmentfrequency and a customer point value.

FIG. 9 is a table illustrating an example of customer point values,customer groups, override groups, and override expiration dates.

FIG. 10 is a diagram illustrating an exemplary capacity allocationhistory screen for use with the computer system of an embodiment of thepresent invention.

FIG. 11 is a worksheet to plan groupings displayed on the computerscreen for use with the present invention.

FIG. 12 is a worksheet to allocate capacity displayed on the computerscreen for use with the present invention.

FIG. 13 is an exemplary view of delivery window grid generated by thesystem of the present invention.

FIG. 14 is a flowchart illustrating generation of the window grid basedon currently available system resources and a customer profile accordingto a specific embodiment of the present invention.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

FIG. 1 shows a schematic block diagram illustrating various systems,subsystems and/or components of an integrated system architecture 100for use with a specific embodiment of the present invention. The systemof FIG. 1 as well as other systems which may be used in conjunction withthe present invention are described in greater detail in copending U.S.patent application Ser. No. 09/568,603 for INTEGRATED SYSTEM FORORDERING, FULFILLMENT, AND DELIVERY OF CONSUMER PRODUCTS USING A DATANETWORK (Attorney docket no. WVANP001) filed on May 10, 2000, the entiredisclosure of which is incorporated herein by reference in all itsentirety. As shown in FIG. 1, system 100 includes a plurality ofsubsystems and other components for effecting electronic commerce over adata network. It will be understood that portions of the varioussubsystems described herein are embodied in computer programinstructions stored in corresponding computer-readable media. A briefdescription of at least a portion of the plurality of subsystems ofsystem 100 is presented below. System 100 of FIG. 1 includes:

(1) a Publishing (PUB) Subsystem 140 which manages SKU and cataloginformation (e.g. SKUs, UPCs, products, categories, descriptiveattributes, etc.), and provides an interface to merchants 133;

(2) a Webstore Subsystem (WS) 132 which manages the on-line storeinterface with customers, including customer shopping and orderingtransactions;

(3) a Transportation Subsystem (XPS) 124 which manages delivery windowscheduling, delivery vehicle routing, capacity planning, and mobilefield device (MFD) data used by delivery couriers;

(4) an Order Management Subsystem (OMS) 150 which manages pricing data,item availability data, inventory data, vendor data, finance,procurement, etc;

(5) an Order Fulfillment Subsystem (OFS) 160 which facilitates thefulfillment of customer orders and manages the distribution center (170)operations; and

(6) a Customer Relationship Management (CRM) Subsystem 126 for enablingcustomer service representatives (CSRs) 143 to service customer requestsand track customer interaction.

According to specific embodiments, each subsystem may also comprise atleast one server and/or other components. Further, each subsystem may beconfigured to utilize a dedicated or shared database server as itspersistent and transactional data backbone. Users or customers mayaccess data stored on one of the subsystem's database servers (e.g.Webstore database), which then executes appropriate business logicand/or business objects.

Each subsystem may be configured or designed to communicate with eachother via a plurality of interfaces. According to a specific embodiment,the plurality of interfaces includes both synchronous and asynchronousinterfaces. Many of the various system interfaces are configured to beasynchronous, wherein data is typically transferred in batch mode viastaging (e.g. database) tables or flat files (e.g., separated valuefiles). However, at least a portion of the system interfaces areconfigured as synchronous interfaces. Generally, a synchronous interfacemay be used where an immediate response from a server or component isrequired.

Conceptually, system 100 of FIG. 1 may be grouped into two generalsubsystems, namely a Front Office system and a Back Office system. TheFront Office system is generally responsible for functions related tocustomer transactions such as, for example, customer orders, billingtransactions, delivery scheduling, customer service, etc. In theembodiment of FIG. 1, for example, the Front Office system 130 comprisesthe Webstore Subsystem 132, Transportation Subsystem 124, and CustomerRelationship Management Subsystem 126. The Front Office system 130 mayalso include other subsystems or components such as, for example, mobilefield device (MFD) components 112, a tax component 114, a billingcomponent 116, a delivery route planning component 118, a search engine120, a catalog component 112, a Help Desk component 114, a customercapacity allocation component 128, etc.

Additionally, the Front Office system 130 may include a centralizeddatabase 131 which may be accessed by subsystems and/or components ofsystem 100. Alternatively, one or more of the Front Office systemsand/or components may each comprise a respective database which isaccessible by other subsystems and/or components of system 100.

The Back Office system generally includes all subsystems and/orcomponents which are not part of the Front Office system. Thus, as shownin FIG. 1, for example, the Back Office system includes the PUB 140, OMS150, and OFS 160 subsystems. However, the invention is not limited tothe particular embodiment shown in FIG. 1, and it will be appreciatedthat the specific configuration of system 100 may be modified by onehaving ordinary skill in the art to suit specific applications.

As shown in FIG. 1, the Front Office 130 comprises a plurality ofseparate subsystems such as, for example, Webstore Subsystem (WS) 132,Transportation Subsystem (XPS) 124, and Customer Relationship Management(CRM) Subsystem 126. Each subsystem may be implemented via a combinationof hardware and/or software, and further may include a plurality ofdifferent functional components, modules, and/or plug-in applications.

At least a portion of the software residing at the Front Office systemmay include a presentation layer, an application layer, a businessobject layer, a database access layer, or any combination thereof.According to a specific embodiment, the presentation layer handles theactual presentation of information to users via an appropriate medium.The application layer handles the appropriate application logic for thevarious subsystems of the Front Office. For example, in the WebstoreSubsystem 132, it is the application layer (referred to as the shoppingengine) which determines that a customer cannot check out an orderunless the customer has selected a delivery window, or provided billinginformation. The business object layer (referred to as the Bobo—Bucketof business objects) provides objects with a fixed set of functionality(e.g. methods or procedures) that may be manipulated by the applicationlayer. According to a specific embodiment, the business objects do notknow about each other, and the application layer handles thecoordination between the various business objects. The database accesslayer provides connectivity and data access APIs to the Front Officedatabase 131 (also referred to as the Webstore database). According to aspecific embodiment, the database access layer performs pooling andcaching of connection objects, where appropriate.

It is also important for a common database schema to be adopted by eachof the Front Office systems. According to a specific embodiment, thedatabase 131 is implemented as a shared database which may be accessedby each of the Front Office systems.

The Webstore Subsystem (WS) 132 provides an interface for enablingcustomers to access the on-line store (e.g. Webstore). In a specificembodiment where the Webstore is implemented as a website on the WorldWide Web, customers may access the Webstore via the Internet or WorldWide Web using any one of a plurality of conventional browsers. TheWebstore user interface may be designed to provide a rich set offunctions without requiring any special browser plug-ins. Thus,according to a specific embodiment, customers may access the Webstoreusing any client machine, regardless of the machine's operating systemplatform. Additionally, for security purposes, the Webstore interfacealso supports data encryption for exchange of any sensitive or privateinformation between the customers and the website. According to aspecific embodiment, the Webstore interface is implemented using asecure http protocol (HTTPS), commonly known to those skilled in theart.

In accordance with a specific embodiment, the Webstore Subsystem 132supports a number of customer related features such as, for example,self registration; accessing of customer account information; browsingof product categories and category hierarchy; viewing of product imagesand product information; key word searches; delivery scheduling;accessing of customer order history; customizable shopping lists;on-line shopping and ordering; etc.

The Webstore Subsystem (referred to as the Webstore) may be implementedusing at least one server which is connected to the data network.According to a specific embodiment, the Webstore is implemented using aplurality of web servers (e.g. web server farm) which helps to minimizeserver response time and provide real-time failover and redundancycapabilities. Further, according to a specific embodiment, in order tokeep the web server response time to a minimum, the Webstore may beconfigured such that all processing is performed on a single server,within one process. Where a plurality of Webstore servers are used,redundant processing may be performed by at least a portion of theservers so that a single Webstore server may handle all Webstoreprocessing tasks associated with a particular on-line customer. It willbe appreciated that the Webstore server boundaries may be crossed whereappropriate, such as, for example, when accessing the Front Officedatabase via the data network.

According to a specific implementation, the presentation layer of the WSsoftware is implemented in ASP, which generates HTML data that is sentback to the customer browser. The application software layer or shoppingengine layer may be implemented as COM objects. The business objectlayer of the software may provide the following business objects: (1) acustomer object which implements customer functionality and attributes;(2) a catalog object which implements the product category hierarchy,SKUs, price, and available-to-promise (ATP) information; (3) an orderobject which implements the shopping cart, order management, billing,and check-out procedures; (4) a session object which implements stateover HTTP; and (5) a delivery object which implements customer deliveryscheduling. Further, the WS is preferably configured or designed tominimize customer response time and to provide for scalability.

Additionally, as shown in FIG. 1, the Front Office system may include anumber of integrated components which provide additional functionality.For example, the WS may include a plurality of components which provideadditional functionality such as, for example, computation of taxes,search capability, credit card billing, etc. Thus, as shown in FIG. 1,for example, the WS 132 includes at least one catalog component 122; atax computation component 114 for computing taxes for each order lineitem that is sold; a search component 120 for processing text searchrequests; and a credit (or debit) card server (CC) component 116 forhandling credit and/or debit card authorizations and funds captures.According to at least one embodiment, one or more of these componentsmay be implemented as an asynchronous process in order to reduce orminimize impact on the Webstore server's response time and availability.

The Transportation Subsystem (XPS) 124 generally handles delivery windowscheduling, delivery vehicle routing, capacity planning, and mobilefield device programming used by delivery couriers. Accordingly, theTransportation Subsystem may be configured to provide the followingfunctional features: (1) delivery grid computation and presentation; (2)delivery scheduling, and delivery window reservation; (3) deliveries tocustomer sites with appropriate billing actions and processing,including processing of adjustments, credits, and returns; (4) adjustingdelivery operation parameters such as, for example, truck route plans,delivery vehicle usage, service duration, parking time, delivery courierscheduling, data to be downloaded into MFDs, etc.; (5) changing orderstate based on cutoff time; and (6) capacity management.

As shown in FIG. 1, for example, the Transportation Subsystem 124 maycomprise a plurality of components and/or other subsystems including,Route Planner 118, MFD server 112, mobile field devices 106,transportation resource management (TRM) software 108, couriers 110, andcustomer capacity allocator 128. In alternate embodiments, at least aportion of these components such as, for example, the MFD server 112,may be implemented as a separate subsystem and may reside external tothe Transportation Subsystem.

Route Planner 118 provides an interface to access the transportationresource management (TRM) software 108. According to a specificembodiment, the TRM component may keep track of the current state of alldelivery windows which may be organized according to a per-zone basis.Delivery vehicles may be assigned to zones as part of the deliveryplanning. The Route Planner 118, working in conjunction with TRM 108,allocates specific routes and stops to specific delivery vehicles.Preferably, a stop will be scheduled for a particular customer withinthat customer's selected delivery time window. When a customer selects adelivery window, the delivery window business object submits the requestto the Transportation Subsystem's Route Planner 118. The Route Plannerthen performs a verification check to verify that the selected deliverywindow can be promised to the customer.

Although the MFD server 112 may conceptually be grouped with theTransportation Subsystem, in a specific embodiment, the MFD servercomponent 112 may configured to include at least one back-end serverwhich resides in a particular area data center. Thus, different areasmay be serviced by different MFD servers. The same may be said for RoutePlanner 118. Moreover, each zone in a particular area may serviced froma station which may be connected to the area data center via the datanetwork. Each mobile field device (MFD) unit or client 106 may connectto an area MFD server 112 via the data network, and download and/orupload various types of information, including, for example, customerorder history information, delivery information (e.g. vehicle deliveryroutes, stops, etc.), customer returns information, credits,adjustments, etc.

The Customer Relationship Management Subsystem 126 is an interactiveapplication which may be used by customer service representatives (CSRs)143 to manage customer service requests and to track customerinteraction. The functionality provided by the CRM subsystem mayinclude, for example, accessing customer information; issuing creditsfor various customer issues (e.g. complaints, returns, damaged goods,etc.); handling work flow for processing customer issues; etc. The CRMsubsystem provides CSRs (sometimes referred to as customer serviceoperators—CSOs) with the ability to access, view, and edit customerinformation in accordance with customer requests.

The Order Fulfillment Subsystem 160 manages all functionality of thedistribution center (DC) 170. In the embodiment of FIG. 1, the OFSincludes appropriate hardware and/or software for managing the DCfacility 170, including, for example, a warehouse management system(e.g. software application), at least one database 161, at least oneinterface 162, and an automated material handling (AMH) controllercomponent 163, which manages the conveyor, carousel, and scannercomponents. In a specific implementation, the Order FulfillmentSubsystem 160 may be implemented using a warehouse management systemsuch as, for example, the MOVE warehouse management system provided byOptum, Inc. of Costa Mesa, Calif. The warehouse system also provides theinterface with the Order Management Subsystem. In a specific embodiment,this interface is implemented using a business host interface (BHI). Thewarehouse management subsystem may also provide the interface forallowing the OMS subsystem to communicate with the OFS database 161.

The Order Management Subsystem (OMS) 150 manages a variety of aspectsrelated to the integrated system architecture of the present invention,including, for example, pricing, availability, inventory, vendors,financials, procurement, and data flows between various subsystems. OMSincludes an inventory component which is responsible for maintaininginventory records, determining inventory availability, and replenishmentof inventory stock. OMS subsystem 150 includes graphical user interface152, and at least one database 151 for storing various data receivedfrom at least a portion of the other subsystems.

The Order Management Subsystem may be configured to support bothasynchronous and synchronous interfaces with the other subsystems. In aspecific embodiment, the OMS is configured to support an asynchronousinterface with each of the other subsystems. This configuration providesa number of advantages described in greater detail below. Additionally,each OMS interface is configurable, and may be configured to support therunning of batch processes as often as is desirable.

According to a specific implementation, all PUB-OMS and WS-OMS interfaceprograms are configured to operate at the database schema level. New andupdated data may be posted to a persistent message queue (e.g. stagingtables) within the data source database. From there, the data may beprocessed into the destination database.

Implementation of the various interfaces between OMS and the othersubsystems may be accomplished using a variety of different techniquescommonly known to one having ordinary skill in the art. The followingdescription provides an example of at least one such technique which maybe used for interfacing OMS with the other subsystems. However, it willbe appreciated that the specific interfaces described below may beimplemented using other techniques commonly known to those skilled inthe art.

The interface between the OMS and the Webstore Subsystem may beimplemented, for example, using a plurality of executable programs. Afirst portion of the executable programs may be responsible for movingdata from the Webstore to the OMS. This data may include, for example,new/updated customer data, new/updated order data, order cutoffinformation, order billing information, customer return information,customer credits and fees (e.g. bill adjustment data), etc. A secondportion of the executable programs is responsible for moving data fromthe OMS to the Webstore Subsystem. This data may include, for example,inventory data, availability data, pricing data, and information aboutshipped customer orders.

FIG. 2 illustrates the “hub and spoke” nature of a product distributionsystem designed according to a specific embodiment of the invention.Trucks 202 leave Distribution Center (DC) 170 to deliver customer ordersto a plurality of stations 204 each of which is associated with a zone206. Each zone 206 may be divided into a plurality of subzones 208 eachof which may contain a plurality of customer stops 210. A plurality ofvans 212 is associated with each station 204 for delivery the customerorders to the appropriate customer stops 210. The orders (comprising oneor more totes) on trucks 202 are transferred to vans 212 at stations 204which then execute an assigned van route according to the deliveryschedule generated as described below.

A specific embodiment of a delivery scheduling process will now bedescribed with reference to FIGS. 3 through 5. When the customer selects“Schedule Delivery” in the Webstore interface (402) XpBobo in WSsubsystem 132 generates and presents a delivery window grid to thecustomer (404), generation of which will be described in greater detailbelow with reference to FIG. 5. When the customer selects one of theavailable delivery windows (406), XpBobo sends the new van stop and theset of routes to the Route Planner 118 for scheduling of the new vanstop on any of the routes (408). According to a specific embodiment,this is done by computing the actual distance between stops usingdriving speeds and a variety of other parameters including, for example,whether or not the selected delivery window is during rush hour.According to a specific embodiment, the scheduling of the new stop on aroute already having scheduled stops is favored. This is achieved byusing a cost model which penalizes adding the stop to a new route butwhich doesn't add any cost for adding the first several, e.g., 6, stopsto the new route. According to a specific embodiment, the Route Plannermodule employs third party software (i.e., TRM 108) called SOC providedby Descartes of Toronto, Ontario, Canada.

If Route Planner 118 cannot place the new stop on any of the routes(410), it may attempt to do so through a process referred to herein as“shoehorning” as long as shoehorning hasn't already been attempted (412and 414). That is, according to a specific embodiment, XpBobo reducesthe service duration (described below) originally set for the new stopand calls the Route Planner to try again with the new value. Accordingto various embodiments, this shoehorning procedure may be repeated someset number of times. If the stop still can't be fit in (410) and no moreshoehorning is desired (412), then a message is presented to the userindicating that the selected delivery window is unavailable (416). If,on the other hand, the new stop does fit into an existing route (410),it is inserted into the route (418).

According to a specific embodiment, when the delivery window grid isgenerated, XpBobo makes the assumption that the customer's order willcorrespond to some number of totes. According to a more specificembodiment, the number is the same for all customers and corresponds to,for example, the average order size in the system, e.g., three.According to an alternative embodiment, the number of totes assumed isbased on the particular customer's past order history; e.g., if thecustomer averages 12 totes per order, the delivery window grid isgenerated based on the assumption that the customer's order willcorrespond to 12 totes this time. However, if the customer has no pastorder history, the delivery window grid is generated based on anestimated size of the order, which is calculated from, for example, theaverage order size in the system.

Referring back to FIG. 4, the number of totes is estimated and updatedat checkout (420) based on the items in the customer's cart andinformation in the catalog about the volume of those items. This isnecessary because in scheduling delivery, the customer is reserving anumber of different types of capacity, e.g., van capacity, serviceduration (i.e., the amount of time allotted for bringing the totes intothe customer's home may change with the number of totes), etc. Thus, atcheckout, XpBobo again contacts the Route Planner with the updatednumber of totes for the purpose of updating the schedule. Any excesscapacity recovered as a result of this updating is then returned to thesystem. If the number of totes does not fit into the van (known as“overloading”), the number will be reduced accordingly until the numberfits into the van. The correct number of totes is also recorded and theextent of the overload is computed.

It is possible that when the Route Planner recomputes the schedule thatthe actual size of the order pushes one or more subsequent stops out oftheir delivery windows in which case the Route Planner rejects theorder. That is, if the customer's stop no longer fits into an existingroute (422), XpBobo may adjust some parameters associated with the stop(424), e.g., the number of totes or the service duration, and resendsthe request to the Route Planner until the order is accepted.

According to another embodiment, even where the customer's stop does notfit into an existing route, it is nevertheless scheduled in the selectedwindow. The window violations are then either taken care of later, e.g.,during a nightly optimization, or handled on a case-by-case basis by theoperations staff.

Each night, another client of Route Planner 118 specifies groups of jobsto be optimized together. This typically opens up additional slack time,i.e., time periods in existing routes, in which additional stops may bescheduled the next day.

An additional optimization occurs at cutoff time, i.e., the time atwhich the orders on a set of van routes are sent to the OFS forfulfillment, by Cutoff Route Planner 302. This provides some fine tuningof the routes as well as takes care of last minute cancellations bycustomers. According to a specific embodiment, where there are multipledeliveries to a single address, this additional optimization maycollapse them into a single delivery.

Each service area, e.g., the San Francisco Bay Area or Atlanta, isdivided into zones corresponding to a particular station, each of whichmay be further divided into subzones. Each of the zones and subzoneshave tables associated therewith which have a plurality of parametersincluding open hours, service duration, parking time, etc. For example,for a particular subzone 6 minutes might be allocated for parkinginstead of 2 minutes for a different subzone. Further detail regardingthese parameters will be discussed below.

According to a more specific embodiment, there is an additional layer oflookup logic in which an address or address range is associated with aspecific latitude/longitude pair and subzone without using the geocodermodule and the polygon interior test. Instead, a direct lookup in adatabase table is performed. This allows the capability to correctgeocoding errors, assign specific addresses to special subzones, and todeny service to addresses that are otherwise in a valid service areawithout having to edit the subzone boundary polygons.

When a customer registers with Webvan, a geocoder module provided byDescartes takes the delivery address and determines a latitude andlongitude pair which Xpbobo then uses to perform a polygon-interior testto determine if the delivery address is in any of its delivery subzones.Each subzone may include multiple polygons. If the address is not in oneof the delivery subzones, the registration module indicates to the userthat the user's area is not currently being serviced. According to aspecific embodiment, the registration module recognizes when thedelivery address is associated with another metropolitan area servicedby Webvan (e.g., by looking at the zip code) and provides theappropriate URL to the user.

If the specified delivery address is within an existing subzone, theaddress is associated with the appropriate zone and subzone and thecorresponding table values. When a customer schedules a delivery, theset of routes and the open hours used in the various transactionsincluding the delivery window grid generation are based upon the tablevalues for the zone and subzone corresponding to the customer's address.The values for a particular zone are inherited by its subzones but maybe overridden. The open hours for a particular subzone would, forexample, override the open hours for the enclosing zone if different.Thus, a particular downtown area may be closed for deliveries duringrush hour while adjacent, less congested areas remain open.

There are five values of interest to the delivery scheduling processwhich may be specified on the zone, subzone, or customer address level.Parking time, base service duration, per tote service duration, stepthreshold, and step duration. The beginning of the service duration fora particular delivery stop must fall within the promised window whilethe parking time does not need to. That is, the driver may park the vanbefore the delivery window, but may not ring the customer's doorbelluntil the delivery window begins.

According to a specific embodiment, parking time is a fixed value foreach subzone (or even for a particular customer) which may evolve overtime based on feedback from drivers. The base service duration is thebasic amount of time it takes to execute a delivery which may bespecified at the zone, subzone, and customer address levels. The pertote service duration is a number of seconds added to the base serviceduration for each tote in the order.

Step threshold and step duration attempt to capture the fact thatcertain orders may require multiple trips between the van and thedelivery location to unload all of the totes. Step threshold identifieshow many totes the driver can carry at once which may be set to takeinformation about the specific customer residence into account, e.g.,the driver can only carry one tote because of access difficulties. Thestep duration is the amount of time to add to the base service durationfor each step threshold reached by the current order. That is, if thestep threshold is 3 and there are 8 totes, 2 step durations are added tothe base service duration. Thus, the total service duration=base serviceduration+n per tote service durations+m step durations, where n is thenumber of totes in the order and m is the number of step thresholdsexceeded.

In the WS database there are two tables which relate to deliveryscheduling. The first table is the Van Routes Table which contains allof the available van routes with their constraints. Rows in this tableare created by XP services component 124 called the Zone Window Creator(ZWC) which runs once a day, e.g., at night, and posts the van routesdata to the WS database. Each entry in this table corresponds to awindow of time during which a delivery resource, e.g., a van, will bedeployed from a particular station to service stops. These zone deliverywindows are also created with reference to the delivery hours in effectfor that zone.

The second table is the Van Stops Table each entry of which correspondsto a customer order which needs to be serviced. Most van stops have apointer which points to a van route in the Van Route Table and includesthe estimated time of arrival and departure if the stop can be serviced.That is, van stops may be created and stored in this table even where itturns out they can't be serviced. In such instances, these entries donot have pointers to particular van routes.

The ZWC creates van routes for the Van Routes Table with reference totruck route plans each of which identifies when a truck is scheduled toleave the Distribution Center and when it is scheduled to arrive at aparticular station. According to a specific embodiment, systemconstraints dictate that when a truck reaches a station there must be aset of vans either at the station or about to return to the station.Each route corresponds to the time period when a particular van is outservicing stops. When the same van returns to the station and thenleaves again, it corresponds to a different route.

The ZWC also refers to the “open hours” for each area and zone, thenumber of vans available in each zone, and a parameter called “staggerduration” which reflects the fact that vans will arrive back at thestation at staggered intervals relative to a particular truck arrivalfrom the DC to ensure that all of the delivery windows are covered by atleast one van. Using all of this information, the ZWC generates the vanroutes each of which indicates when a particular van is scheduled toleave the station to service stops and when it is expected to return.If, for example, three truck arrivals are scheduled for a particularstation on a given day, there are three routes created by the ZWC foreach van at that station.

According to an alternative embodiment, the van return times are notnecessarily constrained by truck arrivals at the station. For example,if a van has enough capacity to stay out longer than the time betweentruck arrivals at the station, then that van is allowed to stay outservicing stops despite the scheduled arrival of a truck at the station.According to this embodiment, vans are only brought back to the stationwhen they are empty.

The generation of the delivery window grid referred to in FIG. 4 willnow be described with reference to FIG. 5. In response to a userselecting “Schedule Delivery” in the Webstore interface, the deliverygrid estimator portion of XpBobo, generates the delivery window gridwith reference to the Van Routes, Van Stops tables, and the currentcustomer's latitude and longitude. According to a specific embodiment,the delivery window grid represents seven days, each having 20-25half-hour windows (depending upon the open hours for the particularzone). The grid represents 7 times 4 sets of 3-6 routes. That is, 7 daystimes 4 truck waves from the DC per day times 3-6 van routes per wave. Aplurality of half-hour windows can be combined to form a 60-minutewindow, a 90-minute window, and the like, which can also be overlappedwith each other.

For each existing van route in the user's service zone, the processcomputes the “slack time” between each pair of existing stops on theroute to determine whether there is sufficient time to deliver astandard load to the user's address. If there are no stops on the route,i.e., the route is still empty, the slack time for that route is theentire duration of the route. The process also determines whether thereis enough free capacity on the van to accommodate the customer's order.According to a specific embodiment, if there is not sufficient vancapacity, XpBobo determines whether a “recharge” trip to the station ispossible between two stops.

Referring now to FIG. 5, initially, all of the delivery windows of thedelivery window grid are designated as unavailable (502). XpBobo thengets the first route for the customer's zone (504) and if there are anystops on the route (506) XpBobo gets the first stop (508) and computesthe slack time between the beginning of the route and the first stop(510). If the slack time is sufficient to accommodate insertion of thenew stop without jeopardizing existing commitments to previouslyscheduled customers (512), the corresponding window in the grid ischanged to indicate that the window is available (514). According to oneembodiment, an graphical element associated with the window is presentedas green rather than red to indicate its availability.

If, on the other hand, the slack time is not sufficient for insertion ofthe new stop (512), XpBobo determines whether the end of the currentroute has been reached (516). If not, XpBobo gets the next pair of stops(518), e.g., the first and second stops, and computes the slack timebetween the pair of stops (510). This continues until the end of theroute is reached (516) at which point, XpBobo determines whether thereare any additional routes for the customer's zone (520). If so, XpBobogets the next route (522) and repeats the process described above. Wherea route does not yet have any stops assigned to it (506), all of thewindows in the grid corresponding to the duration of the route arechanged to available (524). If no routes remain (520) the deliverywindow grid is displayed to the customer (526) and the process ends.

According to a specific embodiment, XpBobo uses two kinds ofcomputations—a “forward” computation by which it computes the “earliestarrival time” at the customer's location, and a “backward” computationby which it computes the “latest arrival time” at that location.

The slack time between existing stops on a route is determined usinginformation from the Van Stops table for the existing stops. Each stophas an associated promised delivery window and a plurality of time-basedparameters the aggregation of which represents the time allotted for thestop. These parameters include drive time to the stop relative to theprevious stop (or the station for the first and last stops), parkingtime, and service time.

When there is any slack between stops on a particular route, a drivingtime estimate is done to determine if there is sufficient time to inserta new stop for the user's address. According to a specific embodiment,this is done without using the absolute real time information from theRoute Planner. Instead, the estimates are computed using approximationsof driving speed and real-driving distances based on straight-linedistances computed from latitude/longitude values. The delivery gridestimator calculates whether a stop is reachable between any twoexisting stops, or the station and an existing stop, or an existing stopand the station, first by computing a forward driving distance from theprevious stop to compute an earliest-arrival time and then byback-computing from the next stop to compute a latest-arrival time.Using these two times and the amount of slack available, it decideswhether a specific window can be shown open to the user.

If there is enough time between existing stops to drive to the newunassigned stop, park, deliver a “standard” load, and drive to thesecond stop without violating existing promises, e.g., the deliverywindow of the second stop, and if there is sufficient capacity in thevan associated with the route, the associated window is presented to theuser as available, e.g., the window is colored green. If there aremultiple windows between the two existing stops for which this is true,all are colored green. As described above with reference to FIG. 5, thisis done for each pair of existing stops on each route. More generally,if there is enough slack time in any of the van routes associated withthe user's service zone for a given delivery window, that window ispresented as available.

According to a specific embodiment, the delivery grid is adjusted forthe open hours available for each day of the week. In the case ofnon-uniform hours, e.g., 9 am to 5 pm on weekends and 7 am to 10 pm onweekdays, the grid is adjusted so that the display is centered correctlyand unavailable times are clearly marked as such. According to a morespecific embodiment, the entire display computation is done in C++ asopposed to ASP and a precomputed grid is handed over to the ASP layerthat then simply displays it as HTML.

As mentioned above, parking time and service duration parameters may beset at the zone level, the sub-zone level, and even at the customer'saddress level. Thus, the parking time may be set high for a particularsub-zone where parking is scarce, or the service duration for aparticular customer might be set high where, for example, the stop has alot of steps. The parking time and service duration parameters may bedetermined considering a customer type (e.g., business or private), anda customer rank. According to a specific embodiment, there are fixed andvariable portions of the service duration parameter. That is, forexample, the service duration is computed based on the number of totesbeing delivered to that stop.

According to a specific embodiment, the module which estimates the drivetime between stops varies the average drive speed used in thecalculation based on the distance between the stops. For example, theaverage speed used is higher when the distance between the stops isgreater reflecting the fact that freeways and expressways are morelikely to be used. According to an alternate embodiment, the drivingtime is determined with reference to the actual along-road distance.

According to a specific embodiment, if a van is determined not to haveenough capacity to add the totes (initially assumed to be three totes)for the new unassigned stop, it is determined whether there issufficient time between existing stops to drive back to the station to“recharge,” i.e., pick up the additional totes. If so, and all of theother parameters fall into place, the window is indicated as availablein the grid.

According to a specific embodiment, certain delivery windows in the gridinclude an indication that a van will be in the user's neighborhood,e.g., a house icon. Such an indication may be included where, forexample, the drive time between a first existing stop and the newunassigned stop (or between the new unassigned stop and a secondexisting stop) is below a threshold value. Alternatively, such an iconmight be displayed where, for example, the customer already has adelivery scheduled, or where it is desirable to provide incentives(financial or otherwise) to select particular windows.

According to another specific embodiment, certain delivery windows maybe displayed as unavailable, e.g., colored red, even though theabove-described procedure would otherwise display them as available,e.g., green. This might occur, for example, where the ratio of drivingtime to the available slack time exceeds some threshold. Using such athreshold avoids driving extremely long distances to serve a singlestop. This approach would tend to show delivery windows as availablewhere additional stops could be accommodated on the way to the new stop.

The capacity management service in the XP services subsystem runsperiodically and queries the WS database regarding reserved totecapacity. Trucks depart the DC en route to the stations in “waves.” Ifthe tote capacity for a particular truck is exceeded by the number oforders, all of the routes corresponding to the vans delivering totes onthat truck are made unavailable for further scheduling by the capacitymanagement service, i.e., their routes are closed. The capacitymanagement service also checks against the tote processing capacity ofthe DC. Customer service operators have the ability to override closedroutes for preferred customers.

Customer capacity allocation is a technique by which the system rationsdelivery windows. According to a specific embodiment, a routine runsevery night which ranks customers according to shipment frequency andaverage order size; the greater the frequency and larger the order size,the more highly ranked the customer. The routine also ranks the deliverywindows according to how long before their scheduled time the windowsfill up; the earlier filled windows being the more desirable windows.The system then allocates or reserves specific percentages of selectedranks of delivery windows to specific percentages of selected rankscustomers. During generation of the delivery window grid, the customer'sranking is taken into account when determining which delivery windows toindicate as available. For example, a highly desirable window might beshown as unavailable to an infrequent customer to ensure that frequentand high volume customers have the best selection of delivery windows.However, if the desirable windows are not filled by the more highlyranked customers at some point before the delivery date (e.g., one ortwo days in advance), they are opened up to all customers to ensure thatthey are filled.

Allocation of System Capacity

An embodiment of a method for allocating the system capacity based oncustomer order data according to the present invention will now bedescribed in detail. In this embodiment, the allocation of the systemcapacity includes the following processes: (i) associating a customerpoint value with each customer according to a customer point system,(ii) dividing customers into customer groups based on the customer pointvalue, (iii) determining an actual capacity allocation distributionamong the customer groups, and (iv) adjusting a demographic distributionof the customer groups.

FIG. 6 is a flowchart illustrating allocation of the system capacitybased on customer order data. Initially, each customer is associatedwith a corresponding “customer point value” according to a customerpoint system (602). The customer point value for each customer isdetermined with reference to customer order data as described in detailbelow.

FIGS. 7 and 8 are factor tables illustrating relationships between anaverage shipment size and a customer point value, and between a shipmentfrequency and a customer point value, respectively. Each customer isassociated with a customer point value based on order history for aspecific period. The customer point value is determined by summation ofpoints based on multiple factors, such as the average shipment size andthe shipment frequency. In this specific embodiment, the multiplefactors are two: the average shipment size and the shipment frequency.However, more than two factors can be utilized for determining thecustomer point value.

One factor is the average shipment size: an average dollar amount fororders made by one customer during a predetermined time window (e.g.,ten weeks). In other words, the average shipment size is the totalamount in dollars for orders made by the customer during the perioddivided by the number of the orders. For example, supposing that acustomer ordered thirteen orders for ten weeks, and the total cost forthe thirteen orders was $780, the average shipment size is $60. Asillustrated in FIG. 7, the customer gets some customer points based onthe average shipment size. The higher the average shipment size is, thehigher the customer's points are. In the above case, the customer'spoints are 25.

Another factor which determines the customer point value is a shipmentfrequency, which is illustrated in FIG. 8. The shipment frequency is thenumber of orders per week for a customer. Similar to the averageshipment size, the higher the shipment frequency is, the higher thecustomer's points are. For example, when a customer ordered thirteentimes for the ten weeks, the shipment frequency is 1.3. In this case,the customer gets 36 points based on the shipment frequency illustratedin FIG. 8.

A level of customer activities is characterized by the average shipmentsize and the shipment frequency. In other words, the customer pointvalue is a summation of points based on the average shipment size, andpoints based on the shipment frequency. Thus, in the above specificexample, the customer is associated with a customer point value of 61(=25+36 points), and each customer point value ranges from 0 (zero)point to 100 points. It should be noted that FIGS. 7 and 8 are specificexamples of how to associate the two factors (i.e., the average shipmentsize and the shipment frequency) with a customer. Therefore,modification of the specific relationships shown in FIGS. 7 and 8, oraddition of a weighting factor for summation of the two factors can beused, and those modification and weighting are included in the scope ofthe present invention.

Referring back to FIG. 6, next, each of the customers is categorizedinto one of customer groups based on the customer point value (604).Each of the customer groups has a corresponding range of customer pointvalues. For example, customer groups A1-A5 have the following ranges ofcustomer point values:

A1: 86-100,

A2: 74-85,

A3: 54-73,

A4: 31-53, and

A5: 0-30.

Thus, the customer in the above example with 61 points is categorizedinto customer group A3. It should be noted that the customer groups canbe divided into different number of groups, i.e., less than five groupsor more than five groups.

FIG. 9 is a table illustrating an example of customer point values,customer groups, override groups, and override expiration dates. Thecustomer table 900 has a customer column 902, a customer points column904, a group name column 906, an override group name column 908, and anoverride expiration data column 910. The customer table 900 has also aplurality of customer rows 910. Each row contains a customer name, acustomer points, a group name, an override group name, and an overrideexpiration data associated with a customer. Any part or all of thecustomer data shown in FIG. 9 can be stored in a computer readable media(e.g., a semiconductor memory or a magnetic/optical disk drive) includedin a computer system for performing the allocation of the systemcapacity. As illustrated in FIG. 9, each customer is associated with acorresponding customer points. For example, the above customer having 61points, “Mary Smith” is categorized into the customer group “A3.” Thus,the customer “Mary Smith” is associated with the customer group “A3” inthe customer table.

A customer service officer (CSO) can override a group name, which isstored in the override group name column 908 with the overrideexpiration date 910. For example, as shown in FIG. 9, the CSO can“upgrade” the customer John Doe from the group name 906 (i.e., A4) tothe override group name (i.e., A3) until the override expiration date910 (i.e., Sep. 30, 1999). After the override expiration date 910, thecustomer John Doe is treated as an A4 customer, which belongs to theoriginal group name 906. Conversely, when the CSO “downgrades” thecustomer Joe Smith from A1 to A3 until Dec. 31, 1999, the system doesnot use the downgraded group name (i.e., A3) since the overridden groupis lower than the original group. In other words, the system uses adominant group name between the original group name and the overriddengroup name. The CSO can upgrade a customer's group (e.g., the customerSunil Bhargava's group name A3) with no expiration date. This privilegeof no expiration date for overriding is given to a “preferred customer,”who is determined to, for example, have made sufficient amount of orderswith sufficient frequency for a sufficient length of time. The systemtypically indicates the CSO's name who overrides the customer's group,and date of the last change.

Referring back to FIG. 6, an actual capacity allocation distributionamong the plurality of customer groups is determined utilizing thecomputer system according to the present invention (606). FIG. 10 is adiagram illustrating an exemplary capacity allocation history screen1000 for use with the computer system of an embodiment of the presentinvention. As shown in FIG. 10, a manager first inputs a begin data 1002and a end data 1004 from a computer connected to the system. A capacityallocation history screen 1000 shows each group 1010, minimum points1012 corresponding to the group 1010, a target capacity allocation 1014,and actual results 1020. The actual results include total customers1022, and total orders 1024.

An Area Customer Manger (ACM) enters the number of days to be used whencalculating points per customer. For example, if the ACM decides thatcustomer order data should be used for 90 days, the ACM inputs 90 (days)as the number of days for calculations. Then, the system of the presentinvention uses the customer order data for the last 90 days in itscalculation from the day of calculation.

The capacity allocation history screen 1000 shows a “new customer” group1030. The new customer group 1030 is a category corresponding to thoseof the customers who have been “associated with the computer system”less than a predetermined period of time. In this specific embodiment,the ACM enters the number of days from first shipment to qualify as a“new customer.” In this specification, a customer is associated with thesystem when the customer's first shipment was delivered (i.e., when thecustomer's earliest purchase occurs). If a customer is qualified as thenew customer group 1030 because the specific days have not passed sincethe first shipment was delivered, then the customer is categorized intothe new customer group 1030 irrespective of the customer point value.For example, if the ACM enters 60 days for the “new customer age,” and acustomer's first shipment was delivered 55 days ago, that customerbelongs to the new customer group 1030. Although the new customer group1030 is positioned between the groups A1 and A2 in this specificembodiment, the new customer group 1030 can be ranked between othergroups. In this specific embodiment, the new customer group isdetermined without reference to the customer point system. In otherwords, as long as a customer is qualified based on the number of dayssince the customer's first delivery, the customer is categorized intothe new customer group regardless of the customer point value. Thus, acustomer belongs to the new customer group if the customer satisfies thenew customer age requirement described above, irrespective of how muchcustomer point value the customer obtains.

The target capacity allocation 1014 is determined by various marketingand administrative factors, and dependent on how much the specificcustomer group should be preferred. For example, when the group A1should be preferred as loyal customers, the ACM sets the target capacityallocation 1014 for the group A1 relatively high.

The total customers 1022 and the total orders 1024 in the actual results1020 are calculated for each customer group by percentage with respectto the total number of the customers (i.e., 23,000) and the total numberof orders (i.e., 5,234), respectively. For example, the group A1 has5,290 customers and 1,780 orders from the begin date 1002 to the enddate 1004. The corresponding percentage values for the customers and theorders are 23% (=5,290/23,000) and 34% (=1,780/5,234), respectively.

The ACM determines an actual capacity allocation distribution among theplurality of customer groups with reference to the customer order dataincluding the average shipment size, the shipment frequency, thequalification as a new customer, and the override group name. The ACMreviews the capacity allocation history screen 1000 considering whetheror not the actual results 1020 are satisfactory distribution compared tothe target capacity allocation 1014. If the ACM finds the actual results1020 unsatisfactory based on the target capacity allocation 1014, theACM can adjust the ranges of the customer point value corresponding tothe customer groups so that the actual capacity allocation distributionto converge to the target capacity allocation distribution. In thisspecific embodiment, the actual capacity allocation distribution isrepresented by the number of the customers and the number of the orders.However, it will be understood that other parameters such as totaldollar amount can be taken into consideration when reviewing the actualcapacity allocation distribution.

The computer system of the embodiment according to the present inventiondisplays a demographic distribution curve of customers in a particulargroup with respect to their customer point values. For example, if thedistribution curve for the group A2 is centered at 77 points, and alarge percentage of the customers in the group A2 ranges from 75-80points, then the ACM would not want to split the group up at 77.

Next, the ACM determines whether the system capacity allocation issatisfactory (608). This determination is made by the ACM in thisspecific embodiment. However, it should be noted that the determinationcan be made by the computer system for use with the present inventionbased on how close the actual results 1020 are to the target capacityallocation 1014. If the decision at 608 is “YES,” then the allocation ofthe system capacity is finished (610). If the decision at 608 is “NO,”then the ACM adjusts the range of the customer point value for aselected customer group (612). This is done by, for example, adjustingthe minimum points 1012.

Then, the computer system for use with the present invention iteratesfrom dividing the customers into the customer groups (604) based on themodified minimum points 1012. This iteration is performed untilsatisfactory convergence of the actual capacity allocation distribution1020 to the target capacity allocation distribution 1014.

FIG. 11 is a worksheet 1100 to plan groupings displayed on the computerscreen for use with the present invention. A recalculation results 1102includes modified minimum points 1104 for the customer groups 1010, andchanged total customers 1106 as a result of the modification of theminimum points 1104. In FIG. 11, the modified minimum points 1104 showsa new minimum points, namely 88 points, for the group A1 which isentered by the ACM. According to the new minimum points 1104, thecomputer system of the present invention categorizes all the customersinto the customer groups with the modified set of the minimum points1104. The system recalculates the number of customers in each customergroup and the percentage of each customer group, and displays thesenumbers and percentages in the total customers section 1106 in theworksheet 1100 on the computer screen. The worksheet 1100 is accompaniedby a recalculate icon 1120 and a submit icon 1122 for instructing thesystem to recalculate the results based on the new minimum points and tosubmit the new minimum points to the system, respectively.

It is noted that the group A5 has minimum points of zero. Thus, allactive customers fall into one of the groups. In this specificembodiment, the customers are categorized into five customer groups.However, in order to avoid heavy prioritization for higher customergroups, the ACM can make, for example, only two customer groups A1 andA2 with a new customer group. In this case, only one group of customerswill see reduced availability of delivery windows in a window grid, andthe reduction is modest. As the user of the system of the presentinvention gains experience of system capacity allocation management, theuser may choose to make more customer groups, and add priority forcustomers in higher customer groups.

FIG. 12 is a worksheet 1200 to allocate capacity displayed on thecomputer screen for use with the present invention. The ACM enters thenumber of expected orders 1202 in the worksheet 1200. The computersystem for use with the present invention displays the customer group1010, and the target capacity allocation 1012 inputted by the ACM, andcalculates the total customer numbers 1204 based on the given minimumpoints for each customer group. For example, the customer group A1 has5,040 customers in total, which corresponds to 21% of the totalcustomers (i.e., 24,000). Then, the system calculates target orders innumber 1206 based on the expected number of orders 1202 and the targetcapacity allocation 1012. For example, the target orders in number 1206for the customer group A1 are 5,760 (=18,000×032). The system calculatestarget orders per week, per customer 1208 by dividing the target ordersin number 1206 by the total customer numbers 1204. For example, Thetarget orders per week, per customer 1208 for the group A1 is 1.1(=5,760/5,040). The worksheet 1200 is accompanied by a recalculate icon1220 and a submit icon 1222 for instructing the system to recalculatethe results based on the new minimum points and to submit the results tothe system, respectively.

In this specific embodiment, a portion of the method of allocatingsystem capacity according to the present invention is performedmanually. Specifically, in the embodiment, the adjusting the minimumpoints 1012 based on the actual results 1020 is performed manually bythe ACM. However, it will be understood that the method according to thepresent invention can be entirely automated by a computer system whichdetermines the allocation of system capacity based on similar criteriaand data on which the ACM relies when allocating.

The capacity allocation report for a certain period of time is generatedbased on the group setting which has not been modified during thatperiod of time. If the capacity allocation report is based on the groupsetting which has been modified during the period, the capacityallocation report can be misleading. Therefore, in this specificembodiment, the capacity allocation report is generated for apredetermined time window (e.g., one week) based on the group settingwhich is the same throughout that time window.

A Customer Service Manager (CSM) can request an override report to beissued from the system using graphical user interface of the system or aprinter. The override report shows the existing overrides, the CSO namewho made the overrides, and the date when the overrides were made sothat CSM can review the overrides of the customer's group name.

Generating Window Grid

Generating delivery window grid in a specific embodiment of the presentinvention will now be described in detail below. FIG. 13 is an exemplaryview of delivery window grid 1300 generated by the system of the presentinvention. The delivery window grid 1300 has rows for seven days fromthe time when a user sees, and columns for half-hour delivery windows.For the sake of simplicity, FIG. 13 shows only a part of the deliverywindow grid 1300. According to a specific embodiment of the method forallocating system capacity of the present invention, the system capacityincludes delivery resources capacity. Specifically, in this embodiment,the system for use with the present invention allocates deliveryresources capacity based on a customer group corresponding to acustomer.

FIG. 14 is a flowchart illustrating generation of the window grid basedon currently available system resources and a customer profile (1400)according to a specific embodiment of the present invention. In onespecific embodiment of the method according to the embodiment, thegeneration of the window grid 1400 is performed between blocks 520 and526 in FIG. 5.

A specific delivery window is not available if delivery resources arenot available for the delivery window. For example, if no vans fordelivery are available for the delivery window, the delivery window isnot available for all customers. Delivery windows which are notavailable solely due to the lack of delivery resources are designated as“X” in the window grid 1300. The computer system first determinesavailable delivery windows based on system resources (1402) by utilizingthe embodiment of the method according to the present inventiondescribed above referring to FIGS. 4 and 5. The “X” delivery windows1302 are not available for all the customers. However, as describedbelow, there are cases in which a delivery window available in terms ofthe delivery resources is not available to some users depending on theusers' customer profile. This delivery resources requirement isabsolute, and thus, other factors cannot override the “X” deliverywindows.

The system for use with the present invention associates the deliverywindows in the delivery grid 1300 with window groups W1-W5 (1404). Thewindow groups W1-W5 represent how “popular” a delivery window is. Inother words, if a delivery window of a specific day (e.g., Friday) and aspecific time of the day (e.g., 5:30 pm-6:00 pm) is selected long aheadof time or selected without fail, that delivery window is popular, andthus, is categorized in a higher window group (e.g., W1). The systemstores the window groups for all the delivery windows which arepresented to the users although these window rankings are not shown tothe users of the system.

The system does not present a delivery window to a user when the windowgroup of the delivery window is higher than the customer group of thecustomer. In other words, the system determines some delivery windowswhich will not be shown to a specific customer based on the customer'sprofile despite of availability of the system resources (1406). For thesake of explanation, suppose that the customer groups A1-A5 are assignedto integers 5-1, respectively, and the window groups W1-W5 are assignedto integers 5-1, respectively. A delivery window is presented to acustomer if an integer corresponding to the customer is equal to orlarger than an integer corresponding to the delivery window. Forexample, if a customer belongs to the customer group A1 (=5), and adelivery window belongs to the window group W1 (=5), the delivery windowis presented to the customer. Conversely, if the customer belongs to thecustomer group A2 (=4), and the delivery window belongs to the windowgroup W1 (=5), the delivery window is not presented to the customer.Thus, an A1 (=5) customer sees all the available windows (=1, 2, . . . ,5) (i.e., all windows other than unavailable windows due to lack of thedelivery resources). An A5 (=1) customer sees only W5 (=1) deliverywindows. A delivery window 1304 designated by “(X)” is a delivery windowwhich is made unavailable based on this comparison between the customergroup and the window group. However, this determination based on thecomparison is overridden by some factors as described below.

There are exceptions to the rule of comparison between the customergroup and the window group stated above. One such instance occurs when adelivery window is close enough to the time when the customer sees thedelivery window grid 1300. For example, the system may make a deliverywindow available to all customers regardless of their customer groupnames when the delivery window is available with respect to the deliveryresources, and the delivery window is close enough (e.g., within 6 hoursfrom the time the user sees the delivery window grid) (1408).

Another instance occurs when a delivery window is preferable to bepresented to the customer from the standpoint of efficiency of delivery(1410). This happens, for example, when a close delivery window in thetime axis has been already reserved to a customer whose delivery pointis close to the user who sees the delivery window grid 1300. In otherwords, if there is a delivery window in which a customer geographicallyclose to the user is going to receive delivery, the system make thedelivery window available to the user, thus efficiently packinggeographically close deliveries into time slots close to each other inthe time axis. In such a case, the system recommends the user to pick upthe preferable delivery window by indicating a green house symbol in thedelivery window grid 1300 shown on a web page. In FIG. 13, the greenhouse symbol is represented by a delivery window 1306 with “H.”

The computer system according to the embodiment of the present inventionfinally generates a delivery interface presenting the delivery windowswhich are available to a specific customer based on the criteriadescribed in the foregoing paragraphs referring to FIGS. 13 and 14(1412).

The specific embodiment of the method according to the present inventionmay utilize weighting factors to further prioritize among the customergroups. Suppose that 100 delivery windows are available to a customerafter comparison between the customer group of the customer and thewindow group for each delivery window. The system can limit the 100delivery windows by multiplying a weighting factor depending on thecustomer group to which the customer belong. For example, the 100delivery windows multiplied by 1.0, i.e., 100 delivery windows areavailable to an A1 customer, where the weighting factor is 1.0. The 100delivery windows multiplied by 0.8, i.e., 80 delivery windows areavailable to an A2 customer, where the weighting factor is 0.8.Multiplying weighting factors prioritizes the customers in differentcustomer groups.

The method of the present invention described above is implemented by acomputer, which generates a delivery interface in which delivery windowsare presented on a remote platform via a wide area network including theInternet.

The computer system for use with the present invention may indicate acustomer's current status on the customer group with which the customeris associated. Specifically, in the embodiment described above, thedelivery interface indicates information based on the group name of thecustomer. Alternatively, the system may indicate how much more orders indollars or frequency will put the customer into the next higher customergroup. For example, the system can generate a message to the customersaying, for example, “To achieve the premier club, you need to ordermore than $ [dollar amount] by [date].” These messages about the currentstatus of the customer may encourage the customer to purchase more.

While the invention has been particularly shown and described withreference to specific embodiments thereof, it will be understood bythose skilled in the art that changes in the form and details of thedisclosed embodiments may be made without departing from the spirit orscope of the invention. For example, the system described above withreference to FIG. 1 is only one system configuration in which thetechniques described herein may be implemented. In addition, thescheduling techniques described herein may also be used for thescheduling of things other than deliveries. For example, the schedulingof appointments could be achieved using the techniques described herein.Therefore, the scope of the invention should be determined withreference to the appended claims.

1. A computer-implemented method for scheduling delivery of products ina customer order, comprising: receiving a piece of information regardingthe customer; displaying a plurality of delivery windows available tothe customer to fulfill the order based on the piece of information;receiving from the customer a selection of a delivery window from theplurality of delivery windows to fulfill the order; and identifying aroute from a plurality of routes to deliver the order, wherein at leastone of the delivery windows is available to one group of customers, butnot to another group of customers, with customers being associated withtheir corresponding group based on information related to their previousorders, wherein whether the at least one of the delivery windows isavailable to the customer depends on the group of customers that thecustomer is associated with, wherein at least one product is held ininventory in anticipation of customer demand, and wherein the method isimplemented by one or more computing devices.
 2. A computer-implementedmethod as recited in claim 1, wherein each delivery window is associatedwith a capacity, and wherein the method further comprises keeping trackof the duration of time to fill the capacity of at least two windows,and ranking the at least two delivery windows based on the trackedduration.
 3. A computer-implemented method as recited in claim 1,wherein the method further comprises keeping track of at least one ofthe frequency of order and the dollar amount of each order of at leasttwo customers, and ranking the at least two customers based on thetracked information.
 4. A computer-implemented method as recited inclaim 3, wherein each delivery window is associated with a capacity,wherein the method further comprises keeping track of the duration oftime to fill the capacity of at least two windows, and ranking the atleast two delivery windows based on the tracked duration, and whereinwhether a higher ranked delivery window is available to the at least twocustomers depends on the rank of each of the two customers.
 5. Acomputer-implemented method as recited in claim 1 wherein the anothergroup of customers has used the method less than a predetermined periodof time.
 6. A computer-implemented method as recited in claim 1 whereininformation related to previous orders of a customer comprisesinformation related to at least one of a customer order frequency and adollar amount of a previous order.
 7. A computer-implemented method asrecited in claim 1 wherein the identifying process favors a route thatalready has at least one previously scheduled stop to fulfill anothercustomer order over another route that does not have any previouslyscheduled stop.
 8. A computer-implemented method as recited in claim 1further comprising considering space on a transportation vehicle todeliver products in the order of the customer in view of at least oneother order to be serviced by the transportation vehicle for theidentified route.
 9. A computer-implemented method as recited in claim 1further comprising determining if there is enough time to deliver theorder without violating an existing promise to another customer.
 10. Acomputer-implemented method as recited in claim 1 wherein at least onedelivery window displayed to be available provides an incentive to thecustomer to select the window.
 11. A computer-implemented method asrecited in claim 1 wherein a delivery window is made unavailable to thecustomer if a distance related to delivering product to the customer tofulfill the order is beyond a certain amount.
 12. A computer-implementedmethod as recited in claim 1 wherein a delivery window previouslyavailable to a first group of customers, but not available to a secondgroup of customers, is made available to the second group of customersif insufficient orders from the first group of customers are placedusing the window after a certain period of time.
 13. Acomputer-implemented method as recited in claim 1 further comprisingindicating to the customer that the customer's status would be improvedif the customer changes a feature related to the customer's order.
 14. Acomputer-implemented method as recited in claim 1, wherein the pluralityof delivery windows displayed as available to the customer depend on thegroup of customers that the customer is associated with.
 15. Acomputer-implemented method as recited in claim 1, wherein each customergroup is associated with a plurality of delivery windows being availableto fulfill orders from customers in the group, and wherein at least onedelivery window is available to fulfill orders from both customergroups.
 16. A computer-implemented method as recited in claim 1, whereinthe piece of information regarding the customer includes an address fororder delivery, and wherein a delivery window is unavailable for thecustomer in view of the address and the time period specified by thedelivery window.
 17. A computer-implemented method as recited in claim 1wherein though a delivery window is not available to the group ofcustomers that the customer is associated with, the delivery window ischanged to being available to the customer due to an attribute of thecustomer.
 18. A computer-implemented method as recited in claim 17wherein the change is effective for a duration of time.
 19. Acomputer-implemented method as recited in claim 17 wherein the change ismanually made and the identity of the person making the change isstored.
 20. A computer-implemented method as recited in claim 17 whereinthough the delivery window should be changed to available in view of theattribute of the customer, the delivery window is not changed in view ofresource availability.
 21. A computer-implemented method for schedulingdelivery of products in a customer order, comprising: receiving a pieceof information regarding the customer; displaying a plurality ofdelivery windows available to the customer to fulfill the order based onthe piece of information; receiving from the customer a selection of adelivery window from the plurality of delivery windows to fulfill theorder; and identifying a route from a plurality of routes to deliver theorder, wherein at least one delivery window displayed to be availableprovides an incentive to the customer to select the window, wherein atleast one product is held in inventory in anticipation of customerdemand, and wherein the method is implemented by one or more computingdevices.
 22. A computer-implemented method for scheduling delivery ofproducts in a customer order, comprising: receiving a piece ofinformation regarding the customer; displaying a plurality of deliverywindows available to the customer to fulfill the order based on thepiece of information; receiving from the customer a selection of adelivery window from the plurality of delivery windows to fulfill theorder; and identifying a route from a plurality of routes to deliver theorder, wherein a delivery window is made unavailable to the customer ifa distance related to delivering product to the customer to fulfill theorder is beyond a certain amount, wherein at least one product is heldin inventory in anticipation of customer demand, and wherein the methodis implemented by one or more computing devices.